There are many use cases for lightweight, low-energy wireless communications protocols, such as Bluetooth®, where the devices need to communicate in real time or near-real time. But often the demands for high rate communications between devices exceeds the capabilities of such wireless communications protocols, as they can often operate too slowly for real-time or near-real time communications.
In wireless charging, it would be beneficial for transmitters and receivers to communicate using low-energy wireless protocols, but it would also be beneficial if the transmitters and receivers could communicate in real time or near-real time. So messages instructing the transmitter how to formulate power waves must be received from the receiver with minimal lag time. However, Bluetooth® was not designed for such rapid communications. Bluetooth® requires senders and receivers to “take turns” responding or not responding, which is prohibitive to achieving or simulating real time or near real time communications. For example, a Bluetooth® client would normally send a request for a data item from a peripheral device and then waits until some data item is received or the Bluetooth® client determines that no response is going to be received.
Furthermore, even if there is a way to increase the rate at which a device could transmit data through a communications protocol, there are often limitations on the hardware responsible for the communications protocol. For example, communications components, such as Bluetooth® chipsets or a Wi-Fi network interface card (NIC), often comprise memory buffers configured to store protocol-specific messages containing the data intended to be transferred between devices. These buffers may be configured to fill and empty according to a predetermined data flow between the devices, according to the particular protocol. In such examples, the buffers may not be capable of allowing for one device or another to continuously transmit data without interruption, outside the normal operational patterns of the protocols. As such, the hardware and firmware of the devices may be limited in their respective communications rates, such that real time or near-real time data transfers are impractical if not impossible with existing lightweight wireless communications protocols.
What is needed is a means for reducing the overhead requirements on devices communicating via a low-energy or other lightweight communications protocol, such as Bluetooth®. What is needed is a means for adjusting or otherwise modifying the data flow between communications components (e.g., Bluetooth® chipsets, Wi-Fi NICs) over conventional communication protocols that would allow data packets or messages to be transmitted from one device to another in real time or near-real time. What is needed is a mechanism through which the limitation of memory buffers filling up and thereby preventing further communication can be removed.